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The  acquisition  of  systems  is  as  much  an  art  as  a  science,  a  premise  that  is 
underscored  by  the  limited  understanding  of  the  variables  found  in  complex 
systems-of-systems.  Moreover,  the  art  and  science  associated  with  acquiring 
systems  has  been  steadily  increasing  in  complexity  as  the  various  technologies 
being  acquired  have  made  huge  advances  in  capabilities.  One  of  the  most 
challenging  types  of  acquisition  to  execute  well  is  that  requiring  the  development 
of  cm  unprecedented  system- of- systems  or  an  ultra  large  scale  system.  The 
challenges  to  the  acquisition  staff  range  the  spectrum  of  those  faced  at  all  levels 
in  the  acquiring  organization  from  that  of  the  most  senior  leadership  and 
management,  through  those  architecting  the  system,  down  to  the  individual 
engineer  executing  technical  tasks  as  a  part  of  the  concept,  design,  developmen  t, 
fielding,  and  sustainment  of  such  systems-of-systems.  Leadership  theory  based 
on  transformational  and  transactional  leadership  styles  assists  in  highlighting 
leadership  problems  in  unprecedented  acquisitions.  Coupled  to  these  challenges 
are  the  clearly  demonstrable  requiremen  ts  for  ever  closer  linkages  between  each 
of  the  discrete  functioned  levels  within  the  acquiring  organization.  The  study  of 
the  essential  nature  of  theses  linkages,  and  how  their  performance  can  severely 
impact  the  probability  of  success  and  effectiveness  of  the  acquisition,  is 
examined  through  the  evaluation  of  a  number  of  exemplar  case  studies.  Using 
analytical  insight  derived  from  these  case  studies,  combined  with  the  application 
of  current  theories  on  leadership  and  management,  this  paper  evolves  the 
tr an s disciplinary  premise  by  articulating  that  leadership  and  technical  execution 
must  be  tightly  linked  especially  when  developing  unprecedented  systems-of- 
systems. 
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1.  Introduction 

Acquiring  complex  systems  in  the  21st  Century  incorporates  both  the  art  of  executing 
an  acquisition  and  the  sciences  necessary  for  dealing  with  complex  system  components. 
Throughout  the  acquisition  of  complex  systems  information  represents  the  life’s  blood 
that  must  flow  freely  between  and  among  all  parts  of  the  acquisition  organization  in  order 
for  there  to  be  an  overall  successful  outcome  (Defense  Acquisition  Assessment  Panel, 
2006,  Vandergriff,  2006,  &  Raduege,  2004). 

This  prevalence  of  information  networking  technologies  have  led  to  the  desire  to  create 
operational  systems  that  are  tied  tighter  and  tighter  together  within  their  enterprise  until, 
ultimately,  the  enterprise  itself  must  be  viewed,  managed,  and  even  acquired  as  a  system- 
of- systems.  To  meet  the  issues  emanating  from  the  variables  associated  with  a  specific 
acquisition,  specific  assumptions  must  be  made  in  order  to  meet  those  outside  variables. 

In  a  broad,  commercial,  context  many  such  systems-of-systems  are  acquired 
successfully.  Examples  of  such  successes  include  integrated  electronic  mail  and  calendar 
services,  financial  accounts  receivable  systems,  and  many  others.  The  differentiating 
point  is  that  these  successful,  complex  systems-of-systems,  by  their  very  existence,  are 
considered  precedented.  In  other  words,  each  such  system  addresses  a  similar 
functionality  developed  earlier  using  older,  less  complex,  technologies. 

The  leadership  and  management  in  a  precedented  acquisition  are  better  able  to 
articulate  a  vision  that  is  not  only  more  easily  understood,  but  also  a  vision  that  the 
technical  people  know  how  to  solve  even  if  the  solution  is  complex  (Luman  &  Scotti, 
1996).  The  executing  management  is  able  to  effectively  measure  the  progress  of  the 
technical  engineering  staff,  as  the  management  has  had  experience  in  which  metrics  have 
been  successful  predictors  of  effective  performance  in  the  past.  Based  on  such  past 
experiences  precedented  systems  are  often  acquired  with  little  difficulties. 

More  challenging  is  when  leadership  envisions,  and  requires,  the  acquisition  of  an 
unprecedented  system-of-systems.  In  this  scenario,  the  unprecedented  nature  of  the 
system  can  lead  to  the  fact  that  the  vision  itself,  as  articulated  within  the  system 
architecture,  may  not  be  easily  understood  as  one  goes  down  the  execution  lifecycle. 
Moreover,  the  technical  engineering  implementers  may  not  know  of  any  architecture  that 
meets  such  a  vision.  The  urge  is  for  technical  engineering  personnel  to  simplify  the 
problem  to  one  they  can  solve.  This  propensity  can  lead  to  a  divergence  between  the 
leadership  vision  and  the  ultimate  technical  solution. 

Moreover,  the  intervening  management  is  unlikely  to  be  measuring  all  the  right  factors 
involved  with  the  technical  tasks,  as  the  unprecedented  nature  of  the  system  means  that 
there  are  areas  that  have  not  been  done  before.  At  bottom,  in  this  scenario  there  is  no 
guidebook  for  which  metrics  to  collect  that  might  serve  as  predictors  of  effectiveness  or 
what  the  values  of  those  metrics  should  be.  In  such  an  environment,  managers  will  likely 
revert  to  measuring  the  unprecedented  project  in  a  way  that  is  predicated  on  how  they 
have  succeeded  in  the  past;  hence  they  will  either  miss  collecting  some  pertinent  metric, 
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or  insist  on  interpreting  the  metrics  as  if  the  project  is  similar  to  the  one  in  the  past.  It  is 
incumbent  upon  senior  leadership  to  remain  aware  of  such  masking  tendencies  and,  while 
being  on  the  look  out  for  indicators,  they  must  also  reinforce  the  original,  unprecedented 
vision.  Once  again,  the  unprecedented  nature  of  the  system  means  such  assumptions 
might  not  work. 

A  major  question  before  us  is  how  should  an  organization  link  between  the  leadership 
level,  through  the  middle-management  level,  to  the  technical  operations  level  so  as  to 
ensure  that  the  vision  and  requirements  are  adequately  articulated?  This  paper  presents 
selected  evidence  of  how  this  critical  linkage  is  difficult  to  forge  or  broken  in 
unprecedented  systems-of-systems,  and  offers  a  leadership  model  to  handle  the  unique 
challenges  of  this  class  of  systems. 

In  order  to  describe  this  connection,  the  paper  is  divided  into  a  number  of  Sections. 
Section  2  addresses  essential  background  information  about  systems-of-systems  and  the 
clarity  differentiating  acquisition  leadership  and  management.  Section  3  discusses  the 
acquisition  leadership  dynamics  that  will  be  considered  while  analyzing  the  case  studies 
by  outlining  the  principles  of  transactional  verses  transformation  leadership,  how  the 
organizational  structures  can  be  described,  and  the  nature  of  the  dynamics  between 
leadership  and  architecture.  Section  4  provides  three  system-of-systems  acquisition, 
development,  and  user  verification  case  studies  and  discusses  the  analysis  of  the 
similarities  and  differences  between  those  cases  and  their  applicability  in  the  evolution  of 
the  leadership  model.  Section  5  provides  the  initial  thoughts  pertaining  to  a  new 
leadership  model  for  application  in  unprecedented  acquisitions.  Section  6  summarizes 
conclusions  drawn  from  this  work  and  provides  suggested  directions  for  future  research. 

2.  Background  and  General  Overview 

This  paper  views  a  system-of-systems  within  the  context  of  transformation  and  net- 
centricity  which  are  the  current  perspective  being  applied  across  the  acquisition 
community  in  the  United  States  Federal  Government.  In  order  for  these  terms  to  be 
harmonized  to  the  authors’  intent,  appropriately  clarifying  definitions  are  provided. 

What  is  a  System- of- Systems! 

In  considering  what  constitutes  a  System-of-Systems  (SoS),  we  first  must  ask  and 
respond  to  the  question  concerning  the  difference  between  a  system  and  a  SoS.  A  straight 
forward  definition  is  that  a  system  is  a  group  of  elements  that  interact  and  function 
together  as  a  whole  (Webster's  ,  1996).  Based  on  this  definition,  a  SoS  would  be  one  in 
which  a  group  of  systems,  rather  than  the  part-elements,  interact  and  function  together  as 
a  whole.  This  has  led  to  the  creation  of  a  series  of  differentiating  characteristics  for 
systems  (Boardman  &  Sauser,  2007);  autonomy  of  component  systems, 
belonging/ownership,  connectivity,  diversity  management,  and  nature  of  emergent 
behavior  handling.  Although  these  characteristics  do  not  give  us  a  strict  definition  for  a 
SoS,  we  can  use  these  characteristics  to  help  us  discriminate  between  a  system  and  a  SoS. 
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For  example,  component-elements  in  a  system  are  subordinate  to  the  system;  however  in 
a  SoS,  autonomy  is  exhibited  by  the  component-systems . 

In  another  example,  the  belonging/ownership  characteristic  of  a  system  indicates  that 
systems  tend  to  be  made  of  components  that  belong  to  that  single  system;  whereas  in  a 
SoS,  the  overall  system  does  not  own  component-systems,  and  indeed  the  ability  to  do 
the  system's  mission  is  wholly  dependent  on  the  component- systems  desire  to  provide 
their  functions.  For  our  purposes,  we  will  consider  SoS  examples  across  the  spectrum  of 
characteristics;  however,  the  essential  aspect  is  that  the  component- systems  of  a  SoS 
must  have  independent,  useful  functions  within  and  outside  the  SoS  and  each  component- 
system  must  be  managed  and  maintained  for  its  own  purpose.  Such  a  stricture  heightens 
the  complexity  associated  when  such  systems  are  brought  together.  Well  known 
examples  of  such  complex  integrations  are  the  many  e-mail,  contact,  and  calendar 
applications;  stand  alone  and  distinct  sub-applications  that  have  been  melded  into  SoS. 

A  counter-example  is  when  multiple  independent  acquiring  agencies  come  together  to 
build  a  system;  if  each  agency  brings  specially  crafted  components,  not  systems  that  are 
functional  outside  the  new  system  being  developed,  then  that  system  is  not  considered  a 
SoS.  Therefore,  only  when  independent  systems  are  brought  together  does  the  true  nature 
of  the  complexity  of  a  SoS  become  apparent.  Often,  when  a  single  acquiring  organization 
is  acquiring  multiple  systems,  by  using  a  single  acquisition  structure  system  complexities 
can  be  heightened  since  many  component  systems  tend  to  be  operationally  and 
managerially  independent.  This  distinction  is  important  in  order  to  fully  comprehend  how 
acquisition  leadership  and  architecture  engineering  can  often  be  separate  and  distinct. 
Moreover,  the  acquiring  senior  leadership  is  burdened  for  in  addition  to  having  to 
understand  the  intricacies  of  the  systems  to  be  acquired,  along  with  the  complexities  of 
their  own  acquiring  organization,  in  order  to  grasp  the  true  magnitude  of  the  complexity 
of  a  SoS,  the  senior  leadership  must  also  look  at  the  entirety  of  the  SoS  lifecycle; 
development,  implementation,  and  verification  at  the  user  level. 

What  differentiates  SoS  leadership  and  architecture  engineering? 

Discussion  on  the  architectural  effort  needed  for  a  SoS  is  presented  by  Luman  & 
Scotti,  (1996).  However,  this  paper  focuses  on  the  work  performed  during  the  execution 
of  an  acquisition  program  that  will  integrate  systems  into  a  larger  SoS.  The  roles  of  the 
acquisition  organization  personnel,  leaders,  managers,  and  architects,  are  normally 
undefined  for  the  SoS.  Rather,  in  a  net-centric  manner,  large  organization  effort  is  placed 
on  enabling  systems  in  acquisitions  to  be  SoS  ready.  It  is  not  within  the  scope  of  this 
paper  to  detail  what  aspects  make  up  net-centricity  nor  the  distinct  differences  between 
systems  interoperability  and  integration  at  the  different  program  levels.  Yet,  there  are  a 
growing  number  of  acquisition  programs  that  lay  claim  to  having  met  the  rigors 
necessary  for  the  executability  of  net-centricity.  It  is  important  to  note  that  success  in  the 
development  phase  of  an  acquisition  lifecycle  does  not  necessarily  connote  success  of  the 
SoS  throughout  its  entire  lifecycle  as  is  found  in  the  case  studies  below. 
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In  SoS,  typically,  methods  such  as  open  architectures,  realized  through  multiple 
numbers  of  technologies,  such  as  sen’ice-oriented  architectures,  are  the  principal  ways 
traditional  system  acquisitions  defend  their  SoS  position  (Luman  &  Scotti,  1996). 
However,  for  each  actual  SoS,  typically  there  is  no  single  program  manager  who  has 
authority  over  the  whole  set  of  component- systems. 

Leadership  and  architecture  engineering  within  SoS  remain  differentiated  at  the  role 
and  responsibility  levels  (Homrig,  2001).  In  normal  circumstances,  architecture 
engineering  takes  place  early  in  the  design  phase  of  the  program  where  influences  that 
will  remain  in  place  for  many  months  or  years  in  an  acquisition,  will  be  posited  during 
this  early  effort.  While  the  architecture  that  has  been  decided  upon  may  be  modified  over 
time,  the  principal  themes  and  goals  normally  remain  intact.  In  a  sense,  we  can  view  such 
an  arena  as  being  generally  stable  and  predictable  even  though  such  architectural 
engineering  may  be  dealing  with  an  unprecedented  SoS. 

The  corollary,  however,  frequently  does  not  hold  for  the  roles  and  responsibilities  of 
the  acquisition  leadership.  The  leadership  roles  and  responsibilities  expand  well  beyond 
the  boundaries  of  any  one  discipline  and  require  that  the  incumbent  leader  not  only  be 
cognizant  of  the  many  disciplines  involved  in  the  SoS  acquisition,  but  also  that  the  leader 
views  the  multitude  of  components,  including  the  people  assigned  to  the  acquiring 
organization,  in  the  SoS  from  a  systemic  point-of-view.  Hence,  there  is  an  early  hint  that 
acquisition  of  unprecedented  SoS  calls  for  a  different,  more  holistic,  point-of-view  on  the 
part  of  the  senior  leadership.  The  leadership  and  architecture  engineering  in  the 
acquisition  of  unprecedented  SoS  find  themselves  viewing  the  acquisition  differently 
based  on  the  roles  being  performed  in  the  program. 

What  differentiates  between  an  unprecedented  verses  precedented  system? 

Finally,  we  need  to  consider  what  precedented  means  with  respect  to  the  architecture 
of  a  system  or  a  SoS.  Precedented  systems,  simply  put,  are  those  that  have  been  built 
before.  This  does  not  mean  that  the  exact  system  in  the  exact  configuration  must  be  built 
multiple  times,  since  that  would  mean  that  only  manufacturing  in  quantity  would 
represent  a  precedented  system.  We  are  considering  a  spectrum  of  characteristics  for 
evaluating  whether  a  system  is  precedented :  functioned  capability,  internalAogical 
organization  of  components ,  and  relationships  to  external  stakeholders  and  systems. 
Considering  these  characteristics  broadly,  the  final  characteristic  is  the  most  unique,  and 
generally  most  descriptive  of  the  precedented  nature  of  a  system  especially  for  a  SoS. 

For  each  of  these  characteristics,  the  architect  must  understand  if  prior  examples  of 
systems,  or  a  SoS,  can  be  applied  in  this  context  and  thus  inform  the  engineers  about  how 
to  design  and  build  the  system.  If,  for  example,  new  data  interfaces  are  going  to  be 
introduced  to  new  users  who  have  never  had  access  to  the  data  before,  then  those 
interfaces  are  unprecedented',  designers  and  engineers  will  not  have  prior  examples  on 
which  to  base  development.  Also,  consider  if  an  agency  is  moving  from  using  human 
judgment  to  automated  analysis,  as  will  be  seen  in  a  case  study  below  in  a  larger  SoS;  in 
this  case  the  system  being  acquired  may  be  unprecedented,  in  that  its  requirements  are 
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more  specific  than  those  that  do  what  the  person  currently  does,  and  may  take  several 
iterations  of  operational  systems  before  requirements  will  accurately  reflect  what  the 
system  requires. 

3.  Acquisition  Leadership  Dynamics 

3.1  Leadership  and  Management 

Regardless  the  human  endeavor,  leadership  has  been  a  common  thread  that  has  run 
throughout.  For  most  of  recorded  history,  leadership  has  been  relegated  to  the  study  of 
traits  that  an  individual  leader  exhibits  or  whether  the  individual  leader  can  be  perceived 
to  be  a  great  man  affecting  his  time.  With  this  history,  leaders  were  normally  measured 
by  the  traits  they  exhibited  that  had  been  found  to  represent  the  best  traits  of  great 
leaders. 

Beginning  with  Taylorism  (Wren,  1994),  the  very  best  men  were  sought  out  as 
representative  not  of  leaders  but  of  the  best  man  for  a  job.  In  order  to  elicit  the  very  best 
from  such  best  men ,  supervisors  were  called  upon  to  better  supervise  or  manage  the 
workers  who  they  supervised.  Hence,  the  evolution  of  management  tools  came  into  vogue 
and  began  to  take  on  the  rhythm  of  a  science  with  appropriate  metrics  and  improvement 
movements.  By  this  juncture,  the  concepts  of  leadership  and  management  diverged. 

This  approach  remained  the  principal  focus  in  management  training  throughout  most 
of  the  last  century.  Extensive  tool-sets  have  been  applied  in  order  to  better  manage 
human  endeavors,  like  acquisitions,  while  the  theoretical  premise  for  leadership  has 
languished.  Toward  the  late  decades  of  the  1980’s  and  1990’s,  it  began  to  be  realized  that 
the  focus  on  managers  doing  things  right  necessitated  a  set  of  talents  that  required 
leadership.  This  focus  led  to  the  understanding  that  effective  leaders  did  the  right  thing 
(Bennis,  1987).  As  stated  by  Kuhn  (1996),  science  changes  paradigms  as  older  theories 
are  found  to  no  longer  be  sufficient  to  explain  the  dynamics  associated  with  changes  in 
impacting  environments.  What  has  led  innovative  thinkers,  in  the  field  of  leadership 
study,  to  newer  premises  is  that,  fundamentally,  leaders  and  managers,  while  ultimately 
striving  for  the  same  long  term  goals,  will  utilize  different  approaches  for  arrival. 

Similarly,  a  large  body  of  work  in  organizational  leadership  theory  was  begun  based  on 
the  seminal  work  by  J.  M.  Bums  (Burns,  2003  &  1978),  and  has  been  focused  on  the 
identifiable  difference  between  performing  work  using  a  transactional  leadership  style  as 
opposed  to  performing  work  using  a  transformational  leadership  style.  The  difference 
may  seem,  at  the  surface,  to  be  moot  because  both  are  valid  leadership  styles  and  would 
be  applied  solely  on  the  whim  of  whether  the  individual  leader  felt  more  comfortable 
with  one  style  or  the  other.  However,  such  has  been  proven  not  to  be  the  case  (Hay,  2007, 
Bass,  Avolio,  Jung,  &  Berson,  2003,  Homrig,  2001,  &  Bass,  1999  &  1990). 

What  has  been  identified  in  the  research  to  date  has  been  that  using  the  transactional 
leadership  style  is  greatly  dependent  on  static,  understood,  and  predictable  situations 
which  are  closely  related  to  the  definition  of  a  precedented  SoS  acquisition.  On  the  other 
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hand,  using  a  transformational  leadership  style  is  greatly  predicated  on  the  situation 
being  unstable,  fraught  with  uncertainty,  and  unpredictable.  These  same  variables  are 
found  in  the  description  of  an  unprecedented  SoS  acquisition. 

To  better  describe  the  difference  between  the  two  leadership  styles,  the  fundamental 
linkage  flows  are  shown  in  Figure  1,  below. 


'Adapted  from  Bass,  B.  M.,  Avolio,  B.  J.,  Jung,  D.  I.,  &  Berson,  Y.  (2003).  Predicting  unit  performance 
by  assessing  transformational  and  transactional  leadership.  Journal  of  Applied  Psychology,  88(2),  207-218. 

Figure  1  -  The  Differentiation  between  Transformational  and  Transactional 
Leadership  Styles 

Take-away  points  include  the  fact  that  in  applying  a  transactional  leadership  style,  as 
on  the  right  side  of  the  diagram,  discrete  transactions  occur  as  the  leader  requires  a 
particular  action  to  be  performed  by  someone  or  some  subordinate  organization  where 
there  is  the  expectation  of  some  measure  of  discrete  reward  being  supported  upon 
completion  of  the  task,  hence  the  basis  of  a  transaction.  The  transactional  approach  is 
closely  linked  to  the  management  of  discrete  tasks,  requiring  little  in  the  way  of  visioning 
or  attention  to  the  individuals  being  tasked.  Moreover,  each  task  can  be  managed 
separately  without  necessarily  taking  other  variables  into  account. 


In  the  case  on  the  left,  depicting  the  more  systemic  perspective  ascribed  to  the 
transformational  leadership  style,  the  leader  makes  a  conscious  effort  to  include  in  his  or 
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her  consideration  all  applicable  variables  associated  with  the  task  or  task-set  that  is  under 
consideration  and  the  broader  programmatic  impact  from  variables  that  are  not  linked  to 
specific  tasks.  This  approach  would  be  held  to  be  systemic  in  nature.  In  keeping  such  a 
systemic  perspective  in  mind,  the  leader  in  question  ensures  that  fewer  unknowns  can 
impact  on  the  discrete  tasks  or  on  the  acquisition  as  a  whole.  Not  that  the  unknowns  will 
not  occur  but  that  they  will,  in  fact,  be  viewed  as  knowns. 

Moreover,  as  Bass  and  Avolio  worked  to  operationalize  Burns’  theory,  they  developed 
the  Multifactor  Leadership  Questionnaire®  that  provided  a  mechanism  for  ascertaining 
specific  components  that  make  up  the  transformational  and  transactional  leadership 
styles  (Avolio  &  Bass,  2006  &  1999  and  Lowe  &  Kroeck,  1996),  and  how  they  would 
impact  the  effectiveness  of  an  organization  in  the  pursuit  of  the  organizational  goals 
(Bass  &  Avolio,  1994). 

As  a  starting  point,  in  Table  1,  is  listed  a  few  of  the  benefits  and  barriers  associated 
with  using  one  leadership  style  over  another. 


Transformational 

Builds  subordinate  capabilities  & 
potential  through  experiences 
Builds  trust,  understanding,  & 
morale 

Encourages  multi-linear  capability 
focusing  on  maintaining  or 
reducing  schedules 
Enables  innovative  approaches  to 
reach  solution 

Enables  perception  of  value  to 
overall  mission  success  and 
effectiveness 

Provides  capacity  for  transfer  of 
knowledge 
Requires  trust 

Requires  appropriate  training 


Transactional 

Maintains  subordinate  levels  & 
grows  individual  experience 
Focuses  on  “wait  for  direction”  work 
ethic 

Encourages  linear  actions  focusing 
on  extending  planned 
schedules 

Has  neutral  impact  on  applying 
basic  solutions 

Limits  perception  of  value  to  overall 
mission  success  and 
effectiveness 

Provides  individual  with  narrow 
experience  profile 
Does  not  encourage  trust 
Does  not  require  much  training  to 
maintain  competency 


Table  1  -  Benefits  and  Barriers  Ascribed  to  Transformational  and  Transactional 
Leadership  Styles 

There  is  not  a  valuation  associated  between  the  two  leadership  styles.  It  is  noted  that 
there  is  not  an  cdl  or  nothing  scenario  ascribed  to  either  leadership  style.  In  attempting  to 
be  effective,  a  leader  who  has  attained  an  understanding  of  the  two  styles  will  judiciously 
apply  the  style  in  the  context  of  the  situation  (Eid,  Johnsen,  Brun,  &  Laberg,  2004).  What 
does  demonstrate  a  differential  between  the  two  styles  is  when  a  leader  has  not  been 
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apprised  of  the  power  of  using  a  transformational  leadership  style,  and  subsequently  he 
or  she  might  not  have  had  the  opportunity  to  study  or  hone  that  capability. 


3.2  Organizational  Structure  Affecting  Success 

When  organizations  are  studied  for  their  efficacy  (Scott,  2003),  the  underlying 
message  that  is  taken  away  is  that  no  one  organizational  structure  fits  all  situations  or  is 
best  suited  for  the  attainment  of  all  goal-sets.  Acquisition  organizations,  however,  tend  to 
be  principally  structured  hierarchically.  In  all  hierarchical  acquisition  organization  there 
exist  a  dynamic  between  leadership ,  management,  and  the  technical  engineers  who 
execute  the  acquisition  programs.  The  mental  model  described  below  addresses  this 
dynamic. 

In  the  authors’  extensive  study  of  the  structural  connections  between  leadership , 
management,  and  technical  engineers  and  those  addressing  the  connection  between  the 
leader  and  the  led,  it  was  found  that  as  research  has  expanded  the  knowledge  base  in  the 
discipline  of  leadership,  more  and  more  frequently  the  various  leadership  concepts  can 
only  be  articulated  using  ever-more  complex  mental  models  of  the  combined  dynamics. 
Initial  leadership  models  were  derived  from  psychologically-based  personality  behavior 
and  trait  research.  However,  those  models  did  not  suffice  yet  have  created  extensive 
leader  behavior  categorizations  that  confuse  leaders  as  to  how  to  execute  their  roles  and 
responsibilities.  Based  on  the  myriad  of  check  lists  and  strictures  posited  by  the 
counseling  hosts,  the  individuals  who  were  charged  to  fulfill  leadership  roles  remain 
unsure  as  to  what  their  relationships  with  their  workforce  are  and  how  the  associated 
dynamics  should  play  out  to  attain  success. 

After  many  years  of  research  and  discussion,  the  realization  came  into  sharp  relief  that 
perhaps  more  complex  models  of  leadership  were  satisfactory  from  a  research  stand  point 
but  such  complexities  were  masking  the  important  messages  about  the  dynamics  between 
leadership,  management,  and  technical  engineering  execution  and,  therefore,  were  not 
accomplishing  the  desired  goal;  the  extension  of  leadership  understanding  and 
application. 

The  context  of  the  dynamics  of  leadership  - followership  (Hock,  1999),  naturally 
drives  toward  a  position  where  senior  leadership  needs  to  be,  or  at  least  needs  to  seem  to 
be,  in  balance  with  middle  management  and  both  are,  or  must  seem  to  be,  in  balance  with 
the  technical  engineers  who  must  execute  the  acquisition  (Sisti,  2007).  Before  describing 
this  mental  model  of  leadership  a  couple  of  critical  definitions  should  be  put  in  place. 

Bcdance  -  Rather  than  use  the  term  homeostasis,  the  word  bcdance  was  chosen  to 
represent  the  dynamic  component  in  the  formula.  This  is  not  balance  in  the  sense  of 
counter-balancing  as  in  a  two-armed  scale  but  rather  balance  in  the  context  of  one 
component  in  the  formula  not  over-burdening  another  component  as  they  exist  in  an 
organization’s  hierarchy. 
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Senior  Leadership  -  The  organization  senior  leaders  are  the  visionary  component 
of  the  organization  and  are  responsible  for  pushing  the  envelope  of  action  in  an 
organization.  It  is  their  role  to  continually  seek  movement. 

Middle-Management  -  The  organization’s  middle -management  constitutes  the 
component  of  the  organization  that  has  the  ability  to  extend  themselves  in  order  to  react 
to  modifications  in  the  organization  that  are  brought  about  by  outside  environmental 
forces  or  at  the  directional  movement  of  the  senior  leaders  of  the  organization. 

Technical  Engineers  -  The  organization’s  technical  execution  engineers  are 
rooted  in  their  place  by  assignment  or  contract  with  very  little  flexibility.  They  look  to 
their  management  and  senior  leadership  to  provide  the  necessary  guidance  and  protection. 

Linkages  -  The  three  components  described  above  have  discrete  roles  and 
responsibilities  within  the  acquisition  organization  the  success  of  which  is  predicated  on 
the  linkages  between  each  of  the  components  singly  and  severally.  It  rests  upon  the 
strength  of  these  linkages  as  to  whether  the  information  flow  that  traverses  the  linkages 
represent  a  benefit  or  a  barrier  to  the  ultimate  success  of  the  organization  and  the 
acquisition. 

With  a  grateful  nod  toward  the  principal  of  parsimony,  Occam’s  razor  (Audi,  1995),  as 
the  premise  for  a  graphical  representation  of  this  model  it  began  to  take  on  a  driving  form 
with  the  goal  to  ensure  that  the  mental  model  was  as  straight-forward  as  possible  while 
still  identifying  the  dynamics  involved. 

Using  a  word-description,  the  model  is  graphically  represented  by  envisioning  an 
individual’s  arm  from  the  elbow  to  the  tips  of  the  fingers,  held  in  a  vertical  position,  with 
the  hand  at  the  top  representing  the  organization  senior  leadership ,  the  forearm 
representing  the  organization  middle-management,  and  the  elbow  representing  the 
organization’s  executing  technical  engineers.  In  the  vertical  position,  it  is  easy  to 
envision  that  if  any  of  the  three  component  segments  are  out  of  alignment,  or  linkage, 
with  one  another,  the  organization  is  out  of  balance  and  hence,  the  effectiveness  of  each 
component  in  the  accomplishment  their  respective  roles  become  dysfunctional  and  often 
contra-productive.  More  importantly,  the  organization  is  placed  in  jeopardy  of  failure. 
The  normal  dynamics  of  the  individual  organizational  components  create  a  constant 
tension  between  them  because  of  the  content  of  their  respective  roles. 

Senior  leadership  is  responsible  for  and  expected  to  take  the  organization  into 
innovative  situations  thereby  generating  risk  of  failure  in  the  organization  but  also  the 
potential  for  advanced  opportunities.  At  the  other  end  of  the  organization  spectrum,  the 
executing  engineers  are  bounded  by  the  constraints  put  in  place  by  the  organization  as 
they  apply  to  a  specific  acquisition. 

It  is  the  organization  role  of  the  intervening  middle-managers  that  is  in  most  jeopardy 
in  this  environmental  tension.  As  senior  leadership  moves  further  away  from  the 
contractual  boundaries  of  the  executing  engineers,  it  is  the  middle-managers  who  are 
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expected  to  act  as  the  buffer  in  dealing  with  the  tensions  created.  Unfortunately,  it  is 
normally  the  middle-manager  who  has  not  been  adequately  prepared  to  deal  with  such 
tensions  and  therefore,  the  organization  is  once  again  in  jeopardy  of  failure. 

It  is  a  solution  for  this  discontinuity  that  calls  for  a  transdisciplinary  approach  to 
applying  successful  leadership  in  an  acquisition  organization,  especially  when  pursuing 
the  acquisition  of  a  SoS. 


3.3  Leadership-Architecture  Dynamic 

In  the  dynamic  between  leadership  and  architecture,  we  need  to  understand  what  an 
architecture  is  and  who  generates  architectures  in  normal  systems.  Then  we  can  examine 
issues  in  how  the  relationship  between  leadership  and  architects  impact  the  system  or  SoS 
being  acquired. 

Architectures  are  defined  by  various  fashion,  but  one  definition  brings  together  many 
of  the  common  aspects:  “Architecture:  ...  (4)  The  organizational  structure  of  a  system  or  a 
software  item,  identifying  its  components,  their  interfaces,  and  a  concept  of  execution 
among  them.”  (IEEE,  2007).  For  a  SoS,  its  architecture  would  consist  of  systems  in 
addition  to  components,  as  not  every  element  of  a  SoS  must  be  a  system.  Although  this 
definition  tells,  us  what  the  architecture  is,  it  does  not  put  that  architecture  into  the 
appropriate  context.  For  that,  we  need  the  architect. 

System  architects,  for  our  purposes,  are  the  people  who  develop  applicable  system 
architectures.  For  most  systems,  this  is  a  function  assigned  to  the  system  engineering 
team  and  delegated  to  an  individual  or  sub-team,  as  explained  in  the  INCOSE  Systems 
Engineering  Handbook  (INCOSE,  2006).  Examining  the  architecture  in  this  way,  we 
differentiate  the  technical  activity  of  achieving  a  consistent  logical  architecture  that  meets 
requirements  from  the  requirements  development  activity  that  would  drive  the  creation  of 
an  architecture.  These  system  architects  establish  the  common  technical  vision  for  the 
teams  of  engineers  that  will  design,  produce,  test,  and  deliver  the  desired  system.  Minor 
divergences  between  the  view  of  these  architects,  managers,  and  senior  leadership  can 
lead  to  a  technical  system  that  is  out  of  alignment  with  organizational  goals. 

To  accomplish  their  goal  of  articulating  a  technical  vision,  yet  not  overly  constraining 
designers  and  developers,  architects  use  a  variety  of  methods,  two  examples  are 
abstraction  and  simplification  (INCOSE,  2006).  In  attempting  to  simplify  the  system, 
architects  must  balance  the  desire  to  model  the  system  in  such  a  way  that  it  appears  as 
simple  as  possible,  but  no  simpler.  An  overly  complex  model  may  be  meaningless  to 
managers  and  senior  leaders,  while  an  overly  simple  model  may  enable  engineers  to  build 
a  system  that  is  not  useful.  In  a  similar  way,  abstraction  is  accomplished  through 
modeling.  If  the  architect  chooses  models  that  are  not  appropriate  to  the  problem 
domain,  then  regardless  of  the  abstraction's  ease  of  understanding,  the  model  may  not 
communicate  essential  information  about  the  system  under  design.  At  bottom,  these 
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abstractions  and  models  help  leaders  and  managers  know  what  details  can  be  “left  in  the 
design  space”.  However,  there  is  a  danger. 

Box  observed  that  “all  models  are  wrong,  but  some  are  useful”  (Box,  1979).  The 
architect  must  utilize  this  fact  in  a  delicate  balancing  act.  In  one  way,  choosing  models 
that  managers  may  already  know  will  help  determine  which  details  are  unimportant  to  the 
given  level  of  discussion,  and  thus  can  be  left  to  the  designers  and  developers.  However, 
when  the  architect  is  working  with  an  unprecedented  system,  or  a  system  in  an 
unprecedented  context ,  models  from  previous  experience  may  abstract  away  details  that, 
while  previously  unimportant,  are  now  essential  to  the  success  of  this  unprecedented 
system. 

For  a  SoS,  Box's  statement  is  even  more  confounding.  Constituent  systems  may  have 
architectures  that  provide  insight  that  was  appropriate  during  their  individual 
developments.  When  composed  with  a  number  of  other  systems,  a  quality  that  is  un¬ 
modeled  in  any  of  the  systems  may  become  essential  for  the  SoS  to  achieve  its  goals.  In 
this  way,  the  models  and  architectures  selected  for  the  component  systems  may  not  truly 
inform  what  needs  to  be  modeled  at  the  SoS  architecture  level. 

Thus,  architecting  an  unprecedented  SoS  is  a  difficult  activity  for  the  architect.  The 
architect  must  figure  out  what  methods  to  employ,  with  the  understanding  that  the 
previous  experience  and  currently  utilized  models  may  be  inadequate  for  expressing  the 
scope  of  the  system  to  the  various  stakeholders.  Over  reliance  on  a  priori  models  may 
result  in  the  utilization  of  models  that  do  not  appropriately  reflect  the  reality  of  the 
system,  or  worse,  force  design  decisions  that  can  cripple  the  needed  system.  In  a  similar 
fashion,  leaders  and  managers  of  architects  must  work  with  the  fact  that  because  the  SoS 
is  unprecedented ,  that  they  must  both  shape  themselves  and  the  architects  to  do  what  is 
necessary  to  deliver  a  successful  system. 

Finally,  acquisition  technical  architectures  provide  the  mechanism  between  which 
technical  and  non-technical  programmatic  elements  harmonize  the  acquisition 
environment.  Elements  such  as  budgets,  contractual  vehicles,  multiple  requirements 
communities,  and  multiple  user  communities  must  be  served  by  the  leadership  and 
management  of  the  acquisition.  Many  of  these  elements  may  have  questions  requiring 
technical  analysis.  Depending  on  the  phase  of  the  program  lifecycle,  the  technical 
execution  may  be  within  the  program  office  (during  concept  definition),  with  the  prime 
contractor  (during  system  design  and  production)  or  in  the  operating  organization  (while 
the  system  is  operational).  Thus  the  architects  must  consider  all  the  issues  raised  in 
developing  a  SoS  architecture  to  serve  all  these  stakeholders. 

4.  Observed  Case  Studies  of  System-of-Systems  technical  (architectural)  interaction 

The  following  three  different  cases  were  selected  because  they  are  representative  of  the 
three  aspects  of  the  acquisition  lifecycle  of  a  SoS  mentioned  earlier;  development  of  an 
unprecedented  technology,  the  operationalization  of  a  SoS,  and  the  verification  that  the 
developed  SoS  meets  the  user’s  needs.  The  three  selected  cases  are  briefly  presented 
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below  as  offering  insight  into  the  linkages  identified  earlier  in  the  mental  model  and  the 
impact  of  such  linkages.  The  selected  case  studies  also  illustrate  where  a  technical 
solution  was  successfully  produced,  but  due  to  mis-alignments  from  the  leadership 
through  the  management  to  the  SoS  architects,  the  systems  ultimately  were  not  successful 
either  from  the  leadership  or  user/customer  viewpoints. 

4.1  MP3.COM  -  unprecedented  technical  success/management  failure 

This  organization  represents  the  operationalization  of  a  European-designed 
MPEG-1  Audio  Layer  3  (MP3),  audio- specific  compression  algorithm  that  was  marketed 
by  Michael  Robertson  beginning  in  the  early  1990’s.  In  bringing  the  technology  to 
market  on  the  internet,  Robertson  tapped  into  a  desired  direct  connection  between  the 
music  consumer  and  the  music  artists  who  agreed  to  use  this  site  as  the  distribution 
network  for  their  copyrighted  works.  The  immediate  success  of  MP3.COM  was 
indicative  of  the  frustration  that  existed  in  the  consumer  base  where  they  are  normally 
forced  to  purchase  an  entire  album  from  outlets  of  one  of  the  major  music  companies 
even  if  the  consumer  really  only  was  interested  in  one  music  track  on  such  an  album. 

While  this  innovative  approach  appealed  to  thousands  of  music  consumers,  the 
natural  limitations  of  the  numbers  of  music  artists  who  had  signed  up  for  MP3. COM’s 
distribution  services  demonstrated  that  the  company  had  to  extend  the  original  innovative 
approach  to  a  broader  base  of  available  music.  This  led  to  the  development  of  the 
MY.MP3.COM  service.  In  order  to  meet  the  goals  of  this  new  service,  MP3.COM  had  to 
literally  have  the  rights  to  every  track  of  music  that  had  ever  been  created.  In  creating  the 
server-based  music  library,  MP3.COM  did  not  necessarily  gain  such  rights.  It  was  at  this 
juncture  when  a  series  of  law  suits  were  brought  against  the  company.  Many  of  these 
were  settled  outside  of  the  court  but  in  one  case,  the  suit  went  to  trial  which  ultimately  led 
to  a  negative  judgment  of  up  to  $53.4  million  against  MP3.COM  for  copyright 
infringement. 

Mr.  Robertson  eventually  sold  the  company  to  Vivendi,  Inc.  which  in-turn  sold  it 
to  CNET  NETWORKS  which  now  operates  the  company  without  the  music  library. 

4.2  Surface  Assessment  Robot  (Integrated  Construction  Management)  -  use  of  a 

precedented _ technical _ solution _ in _ unprecedented _ operational 

environment/manasement  failure 

The  case  of  the  surface  assessment  robot  (Latimer,  2007)  outlines  a  technical  triumph, 
but  an  overall  acquisition  failure.  This  robotic  system  was  intended  to  replace  the  manual 
inspection  process  that  assesses  the  smoothness  of  a  roadway  to  be  used  by  automatic 
vehicles  with  standing  passengers.  Overall,  the  system  delivered  a  100-to-l  return  on 
investment  (realized  through  greater  than  100-to-l  savings  on  operations  effort  for  the 
inspection),  which  included  funding  its  research  and  development  in  the  first  operational 
evaluation.  However,  ultimately  several  factors  regarding  how  the  acquirer  viewed 
potential  architectures  led  to  an  over-constrained  situation  that  prevented  the 
development  of  an  operationally  suitable  system. 
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To  the  acquirer,  the  requirements  essentially  were  to  “do  the  inspection  like  our  best 
expert”.  The  development  team  had  access  to  the  expert  over  many  technical  meetings, 
field  observations,  and  personal  interviews.  Also,  the  development  team  became  familiar 
with  all  the  various  contractual  obligations,  requirements  from  the  licensed  civil  engineer 
who  oversaw  the  roadway  construction,  and  organizational  requirements,  which  included 
requirements  for  collecting  and  reporting  process  deviation  information  to  a  quality 
assurance  and  process  improvement  office. 

The  issue  rapidly  came  to  a  point  in  a  difference  between  the  designers  at  the 
developer  and  the  acquirer's  engineers  about  how  best  to  use  profile  data  to  identify  road 
smoothness  deviations.  After  the  principal  road  profile  sensor  was  selected,  the 
developers  wanted  to  simulate  traffic  over  the  sensed  profile,  to  determine  if  the  ride 
quality  of  that  profile  is  sufficient.  However,  the  acquirer  wanted  to  treat  the  profile  like 
the  human  and  only  identify  when  absolute  deviations  occurred  in  the  profile  (essentially 
when  the  amplitude  of  the  roll  of  the  road  exceeds  a  certain  threshold  over  a  given 
length).  The  acquirers  insisted  that  their  method  was  how  the  field  inspectors  operated, 
and  that  method  must  be  how  the  new  robot  interprets  the  data. 

At  the  same  time  this  is  occurring,  the  acquiring  company  was  being  bought  by  a  new 
parent  company.  In  this  new  parent  company,  innovation  was  to  be  performed  “off-the- 
shelf’.  The  new  parent  company  did  not  believe  in  sponsoring  custom  developments, 
preferring  instead  to  utilize  systems  that  would  have  long-term  support  from  a  vendor. 
Since  the  corporate  resources  for  the  project  had  been  committed,  the  project  was  allowed 
to  continue,  with  the  understanding  that  the  acquirers  and  developers  would  only  have 
one  operational  assessment  opportunity  to  demonstrate  their  system.  This  environment 
prevented  any  form  of  competition  between  the  ideas  of  the  acquirers  and  developers.  In 
this  case,  the  acquirers  prevailed  in  directing  that  their  method  of  interpreting  the  data 
would  be  utilized.  Although  the  topology  of  the  architectures  between  the  acquirers  and 
the  developers  was  the  same,  the  nature  of  one  of  the  boxes,  and  thus  the  exact 
information  that  would  be  relayed  to  the  whole  enterprise,  was  fundamentally  different 
between  the  two. 

When  the  system  was  finally  brought  out  to  the  field  for  operational  assessment  on  a 
freshly  constructed  road,  the  system  marked  two  orders  of  magnitude  more  deviations 
than  anticipated.  Initially  believed  to  be  false  positives,  on  manual  inspection,  all  the 
deviations  were  validated.  This  came  as  a  surprise  to  acquirer  and  developer  alike.  The 
developers  had  access  to  sample  roadways.  However  the  roadways  had  been  used  for 
testing  by  the  acquirer  for  years,  resulting  in  a  smoothing  out  of  the  very  minor 
deviations.  Further,  the  inspector  indicated  that  most  (99%)  of  the  deviations  were  so 
minor  that  he  would  not  have  reported  them.  This  fact  had  not  been  observed  during  the 
field  observations,  nor  in  any  interviews.  Due  to  this  fact,  and  some  additional  concerns 
about  the  operations  mode  of  the  robot  which  as  a  sensing  system  required  calibration, 
the  system  was  not  utilized  beyond  the  operational  assessment. 
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4.3  Force  Transformation  -  A  Network-Centric  Operations  Case  Study:  US/UK 
Coalition  Combat  Operations  during  Operation  Iraqi  Freedom  -  unyrecedented 
technical  success/leadership  &  management  failure 

The  Department  of  Defense  Office  of  Force  Transformation  conducted  the  subject 
Network-Centric  Case  Study  in  2003  to  assess  United  States  Forces  and  United  Kingdom 
coalition  combat  operations  using  the  Network  Centric  Operations  Conceptual 
framework  as  the  basis  for  analysis.  The  common  development  product  on  which  the 
study  was  focused  was  the  utilization  and  efficacy  of  the  Force  XXI  Battle  Command 
Brigade  and  Below  (FBCB2)  Blue  Force  Tracker  (BFT),  or  the  FBCB2/BFT  System  as  it 
is  commonly  known,  as  the  demonstration  (Office  of  Force  Transformation,  2005).  This 
was  to  be  a  comparative  study  with  the  researchers  positing  that  each  set  of  coalition 
units  use  as  a  baseline  the  situational  awareness  data  provided  by  whatever  mechanisms 
and  equipments  that  the  units  had  used  in  the  past,  prior  to  the  receipt  and  training  on  the 
FBCB2/BFT  equipment.  Moreover,  the  FBCB2/BFT  concept  represents  a  SoS  based  on 
the  facts  that  the  FBCB2/BFT  equipment  are  made  up  of  a  Global  Positioning  System 
mounted  on  unit  vehicles,  using  satellite  communications  extensively  to  move  massive 
amounts  of  friendly  unit  data  around  the  battle  zone  in  a  secure  manner,  and  in  a 
relatively  short  period  of  time  making  coalition  ground  commander  decision-making  as 
real-time  based  as  possible. 

While  the  original  intent  of  the  study  was  designed  to  ascertain  the  improved 
situational  awareness  provided  through  use  of  the  FBCB2/BFT  SoS,  between  coalition 
forces,  it  was  found  that  there  were  limitations  in  place  because  of  the  difference  in  the 
numbers  of  FBCB2/BFT  systems  that  were  deployed  in  the  combat  units  of  the  selected 
United  States  Forces  and  those  of  the  United  Kingdom.  In  short,  this  limitation  meant  that 
the  researchers  had  far  fewer  available  users  to  interview  in  the  United  Kingdom  Units 
than  the  number  that  were  using  the  equipment  in  the  United  States  Forces.  An  original, 
extensive,  interview  plan  that  had  been  developed  was  modified  when  the  research  team 
was  in  country  based  on  the  lower  density  of  actual  system  users  that  were  found  within 
the  United  Kingdom  forces. 

Even  with  the  limitations  presented  by  the  density  of  FBCB2/BFT  equipment,  the 
study  was  conducted  and  the  available  data  was  analyzed.  The  reported  analysis  reflects 
the  lowered  density  of  equipment  and  hence,  limited  coalition  conclusions  were  drawn. 
The  researchers  were  able,  however,  to  provide  additional  clarity  concerning  the 
situational  awareness  and  the  dissemination  of  that  information  among  impacted  units 
thus  verifying  earlier  development  conclusions.  It  was  noted  that  the  lower  density  of 
FBCB2/BFT  equipments  found  in  the  United  Kingdom  Units  had  been  based  solely  on 
decisions  made  by  their  Unit  Command  and  Control  hierarchy. 


4.4.  Analysis 

In  the  case  of  the  Surface  Assessment  Robot  we  observe  a  situation  where  the 
leadership  of  the  sponsoring  company  desired  a  transformation  of  their  business. 
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However,  when  execution  began,  leaders  and  managers  lacked  the  ability  to  change 
themselves,  to  adapt  themselves  and  their  guidance,  to  bring  this  precedented  technology 
to  their  enterprise  in  an  unprecedented  fashion  to  achieve  their  goals.  In  many  ways,  the 
leaders  and  managers  desired  a  Commercial-Of-The-Shelf-like  solution  that  could  be 
plugged  into  their  organization  with  minimal  perturbation  of  people's  view  of  their  jobs. 
The  inability  of  the  leadership  and  management  to  operate  an  in  transformational  fashion 
led  to  a  prescriptive  requirements  environment  where,  although  the  developers  conceived 
of  transformational  solutions,  the  required  trust  was  not  present  to  enable  leaders  and 
managers  to  accept  those  solutions. 

In  this  case,  the  system  developers  were  able  to  get  linkages  established  between 
the  various  entities  that  were  going  to  be  impacted  by  the  new  surface  assessment  robot. 
Through  a  significant  number  of  stakeholder  meetings,  stakeholders  were  kept  well 
informed  about  how  the  robot  was  being  designed  and  would  operate  to  meet  their 
individual  goals.  However,  the  architecture  effort,  while  significant,  was  only  successful 
in  guiding  the  downstream  design  and  development  activities,  and  had  no  success 
working  to  change  the  operational  environment  or  get  transformational  involvement  from 
the  customer  stakeholders.  Thus,  due  to  the  transactional  approach,  a  set  of  requirements 
were  established  that  had  no  valid  design  space.  This  meant  that  no  system  could  be 
designed  that  could  meet  the  requirements,  due  to  inherent  conflicts  within  the 
requirements.  Of  course,  there  was  no  way  to  objectively  demonstrate  that  this  was  the 
case,  because  no  models  existed  for  the  architects  to  show  that  these  requirements 
wouldn't  work.  Essentially,  due  to  the  unprecedented  operational  concept,  designers, 
architects,  managers,  and  leaders  did  not  know  their  expression  of  the  system 
requirements  was  unachievable.  Ultimately  this  was  demonstrated  when  the  robot  was 
deployed  for  its  operational  assessment,  and  while  the  customer  validated  that  the  robot 
met  its  requirements,  including  business  case  requirements,  those  requirements  did  not 
lead  to  a  robot  that  would  satisfy  their  desires.  Thus,  the  robot  remains  unused  to  this 
day. 


In  the  case  of  the  MP3.COM,  we  see  the  operationalization  of  a  precedented 
technology  in  an  unprecedented  approach  using  the  internet.  With  the  creation  of  the 
company,  the  older  technology  was  connected  to  the  internet  in  a  manner  in  which  the 
most  efficient  methodology  for  presenting  commercial  music  selections  to  a  demanding 
consumer  public  led  to  a  SoS  that  effectively  removed  the  middleman  represented  by  the 
large  music  distribution  companies  and  their  wholly  controlled  music  outlet  retail  chains. 
In  retrospect,  this  operationalization  was  extremely  effective  and  initially  the  largest 
problem  that  MP3.COM  faced  was  a  matter  of  being  able  to  scale  up  to  meet  the  huge 
demand  that  resulted. 

Initial  success,  however,  called  for  a  well  thought  out  strategy  for  avoiding  entangling 
law  suits  based  on  copyright  infringement.  What  the  senior  leadership  of  MP3.COM 
never  grasped  was  that  they  had  to  deal  with  more  than  the  consuming  public.  Theirs  was 
wholly  a  transactional  leadership  environment  based  solely  on  the  service  provided  the 
paying  consumer  hence  creating  no  linkages  that  would  assist  in  protecting  the 
organization  when  the  competition  regrouped  and  used  the  copyright  law  against 
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MP3.COM.  The  senior  leadership  needed  to  have  used  a  transformational  focus  since  the 
environment  was  so  unstable  and  they  needed  to  have  prepared  and  structured  themselves 
to  protect  their  success  from  the  larger  music  chains  that  were  losing  revenue  and  control. 
Neither  of  these  approaches  was  adequately  applied.  The  necessary  linkages  had  been 
ignored  creating  a  deadly  void.  The  mechanism  that  was  used  against  MP3.COM  was  to 
focus  on  this  void  with  a  flurry  of  copyright  lawsuits.  Eventually,  MP3.COM  was  unable 
to  satisfy  the  judgments  and  the  company  was  sold  out  from  under  the  originators. 

In  the  case  of  the  Network-Centric  Operations  Case,  the  study  itself  was  based  on  the 
unprecedented  SoS  of  the  FBCB2/BFT  concept  and  was  originally  designed  to  reflect  the 
impact  of  situational  awareness  data  within  and  across  coalition  forces.  That  objective 
was  not  obtained.  The  research  effort  was  ultimately  considered  a  success,  as  is  of  course 
the  FBCB2/BFT  equipment.  However,  the  research  results  provide  insight  into  significant 
application  deficiencies  that  can  only  be  attributed  to  leadership  failures. 

Although  this  was  a  study  of  coalition  situational  awareness  connections  using  the 
FBCB2/BFT,  there  had  not  been  adequate  architectural  engineering  applied  earlier  in  the 
equipment  roll-out  so  the  density  issue  was  bound  to  cause  problems  later  on.  Those 
problems  surfaced  during  this  verification  research.  What  is  of  note  was  that  the  decision 
to  use  a  lower  density  of  the  FBCB2/BFT  equipments  was  dictated  by,  and  internal  to, 
the  United  Kingdom  units  themselves.  This  decision  had  a  direct,  negative,  impact  on  the 
ability  of  the  highly  successful  FBCB2/BFT  equipment  to  raise  the  overall  situational 
awareness  between  the  coalition  forces.  Additionally,  the  capabilities  of  the  concept  that 
make  this  a  SoS  were  limited  to  the  extent  where  the  conceptualization  of  the  original 
SoS  came  under  question.  In  short,  the  linkages  between  the  senior  leadership  of  the 
United  Kingdom  units  and  their  field  users  were  of  insufficient  robustness  to  have 
resulted  in  the  equipment  system  being  adequately  acquired,  stressed,  and  measured. 

That  this  disconnect  was  observed  during  a  neutral  research  effort  provides  a  well 
documented  lessons  learned,  not  necessarily  on  the  effectiveness  of  the  FBCB2/BFT 
concept  and  equipments  but,  rather,  on  the  extent  to  which  coalition  forces  need  to  have 
equal  capabilities  provided  from  appropriate  sources  if  the  original  goal  structure  and 
mission  success  were  to  be  obtained. 

In  Table  2,  the  three  cases  are  arrayed  so  that  the  reader  can  see  how  the  authors  rated 
the  variables  under  consideration.  Since  the  three  cases  represent  different  phases  in  a 
SoS  lifecycle  no  comparison  between  cases  is  intended.  What  is  intended  is  to  point  out 
to  the  reader  that  major  disconnects  exist  in  the  critical  execution  of  leadership  issues  in 
each  of  the  selected  cases.  Additionally,  it  should  be  noted  that  each  of  the  cases  had  a 
component  that  resulted  in  a  categorization  of  being  successful. 

In  the  Surface  Assessment  Robot  Case,  accomplishing  the  technology  development 
was  certainly  a  success.  In  the  case  of  the  MP3.COM  SoS,  the  initial  consumer  set 
certainly  viewed  it’s  establishment  as  a  huge  success  over  the  earlier  total  control  over 
the  music  industry  by  a  few  very  large  companies.  However,  the  linkages  failed  to 
materialize  that  would  retain  the  early  success  and  ultimately,  the  MP3.COM  failed  and 
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is  still  operating  but  as  a  shadow  of  its  original  self  and  promise.  In  the  Network-Centric 
Operations  Case,  the  SoS  components  that  were  focused  on  United  States  Forces,  have 
been  a  resounding  success,  yet  when  extended  to  the  critical  coalition  United  Kingdom 
forces  the  entire  purpose  for  existence  eluded  the  coalition  connection. 


Variable/ 

SoS  Case 

MP3.COM 

Start-Up 

SA  Robot 
Development 

FBCB2/BFT 

Study 

Comment 

Organization  Structure 
(Transactional  in 
Nature) 

Large 

Large 

Large 

Organization  Structure 
(Transformational  in 
Nature) 

Small 

Small 

Small 

Architecture 

Engineering 

Small 

Medium 

Medium 

Linkages 

Established 

Small 

Medium 

Small 

Decision  Agents 

Being  Well  Informed 

Medium 

Large 

Large 

Technical  Expertise 

Large 

Large 

Large 

Legend  -  Level  of  Effort :  Small,  Medium,  &  Large 


Table  2  -  SoS  Case  Studies  by  Variables 
5.  Initial  Thoughts  on  a  Leadership  Model  for  Acquiring  Unprecedented  SoS 

While  performing  their  acquisition  work  roles  over  the  past  decade,  the  authors  have 
been  surprised  and  dismayed  to  find  that  there  has  been  no  effort  devoted  to  casting  light 
on  the  connecting  dynamics  described  above  in  acquisitions  of  both  precedented  and 
unprecedented  systems,  other  than  the  reliance  of  attempting  to  refine  management 
techniques.  Additionally,  issues  associated  with  rising  complexity  across  and  among 
systems  being  acquired,  pose  a  growing  dilemma  as  to  whether  current  management 
techniques  will  ever  be  robust  enough  to  handle  organizations  in  the  future  that  are  going 
to  be  called  upon  to  deal  with  this  change  in  acquisition  paradigms. 

As  the  bulk  of  the  affected  acquisition  community  continues  to  refine  management 
techniques  in  the  hope  that  at  some  point  they  will  attain  that  place  of  balance  where 
acquisitions  respond  positively  to  the  simple  application  of  these  refined  management 
mechanisms,  it  becomes  more  and  more  evident  that  this  hope  is  not  a  success-oriented 
approach  to  the  growing  situation.  Two  issues  obtain;  there  is  virtually  no  clear 
understanding  of  the  differences  between  the  distinctly  roles  and  responsibilities  of  the 


Journal  of  Integrated  Design  and  Process  Science 


June  2007,  Specicd  Issue 


19 


senior  leader,  middle  manager,  and  technical  engineer,  and  there  is  only  a  limited 
understanding  of  the  impact  that  transformational  and  transactional  leadership  styles 
have  on  the  effectiveness  of  an  acquiring  organization  and  the  overall  acquisition.  This 
paper  is  designed  to  begin  filling  this  compound  gap  in  our  ability  to  acquire 
unprecedented  SoS. 

The  necessary  leadership  model  under  development  will  have  to  meet  a  number  of 
specific,  and  orthogonal,  criteria  in  order  for  it  to  become  successful;  (1)  it  must  be  as 
simple  as  possible  but  no  simpler,  (2)  it  must  be  representative  of  a  living  system,  a 
concept  extensively  articulated  in  Miller  (1978),  (3)  it  must  include  a  point-of-view  that 
encompasses  all  of  the  variables  that  impact  the  unprecedented  SoS  in  question,  (4)  it 
must  be  robust  enough  to  incorporate  the  linkage  dynamics  associated  with  the  acquiring 
organization’s  hierarchical  structure  in  order  to  ensure  acquisition  success  across  the 
whole  lifecycle  including  development,  operationalization,  and  user  verification,  and  (5) 
it  must  be  encompassing  in  scope  so  that  the  theory/model  can  easily  adapt  to  the  type  of 
the  SoS;  and  therefore,  the  leadership  approach  is  agnostic  as  to  SoS  type,  condition,  or 
situation.  In  short,  the  proposed  leadership  model  must  be  a  Systemic  Leadership 
Theory/Model.  For  such  a  theory/model  to  be  developed  it  must  be  predicated  upon  a 
trans disciplinary  base.  This  paper  lays  the  groundwork  for  such  a  step  in  the  first  decade 
of  the  21st  century  acquisition  environment. 

6.  Conclusions 

The  paper  has  identified  the  fundamental  flaws  to  be  found  in  today’s  acquisition 
leadership  and  management  approaches  to  SoS  acquisitions.  Where  acquisitions  have 
been  focused  on  precedented  systems  success  has  been  attainable  in  the  past  but  as 
growing  complexity  and  requirements  force  more  unprecedented  acquisitions  to  be 
attempted,  past  points-of-view  no  longer  obtain.  Success  becomes  less  and  less  attainable 
without  unlimited  resources  and  time  being  factored  into  the  initial  plan.  Since  that 
perspective  is  inappropriate,  a  fresh  look  has  to  be  taken  at  the  variables  that  exist  in 
today’s  acquisitions. 

In  order  to  establish  a  common  frame  of  reference,  specific  terms  call  for  clarification 
and  broad  understanding.  Whether  the  acquisition  is  acquiring  a  system  or  a  system-of- 
systems  becomes  an  important  differentiator  as  does  the  understanding  of  whether  the 
acquisition  is  precedented  or  unprecedented.  Moreover,  success-oriented  acquisition 
organizations  require  that  a  clear  understanding  exists  relating  to  the  respective  roles  and 
responsibilities  of  the  acquisition  senior  leadership,  middle -management,  and  technical 
engineers.  To  fully  understand  how  those  roles  and  responsibilities  will  be  identified  and 
applied,  the  acquiring  organization  must  understand  the  difference  between  leadership 
and  management  and  between  transactional  and  transformational  leadership  styles. 
Without  these  common  understandings,  all  attempts  at  establishing  architecture, 
organization,  tools,  techniques,  and  legal  boundaries  suffer. 

The  authors  have  engaged  the  laying  out  of  the  problem  and  begun  the  evolution  of  an 
answering  theoretical  approach  and  model  in  a  Systemic  Leadership  Theory/Model. 
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